home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16069 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 07:27:51 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829048603@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg> <4kbuebINNrho@keats.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. "This is so deeply entrenched in the realm of common sense that it isn't even
  13. worth mentioning in a standard document! Nevertheless, I have access to the
  14. POSIX.1 standard and will look into this."
  15.  
  16. This seems complete nonsense. There are two possible semantics that ould
  17. be defined for read (buffer must be at least size of the read argument,
  18. or buffer must be at least size of data read). Both are easy to specify,
  19. both are easy to implement. You cannot rely on common sense (especially
  20. dubious reasoning about kernels and what not that are totally irrelevant
  21. to the semantic specification). The idea that specs are derived from
  22. implementations (either by looking at the implementation, or reasoning
  23. about it with "common sense" or otherwise) is completely unacceptable!
  24.  
  25. (though unfortunately very common, especially when people are writing in 
  26. a language that does not make a big deal about separating spec and
  27. implementation details).
  28.  
  29. My only at-hand sources are K&R, which has nothing whatever to say on 
  30. the subject, the Zortech C++ reference, which also has nothing to say,
  31. (both describe read, but say nothing about the buffer length), and
  32. the Microsoft Runtime Reference which talks about "attempting to
  33. read n bytes", but is otherwise unclear.
  34.  
  35. We are after all dealing with a language interface where in practice the
  36. proper check (whichever it is) cannot be made, because the called routine
  37. does not know the length of the buffer passed. I think a natural default
  38. assumption, in the absence of any statement to the contrary, is that the
  39. bytes are blindly read into the buffer, and disaster strikes if the number
  40. of bytes read is greater than the buffer length, but otherwise all is well.
  41. Unless there is a VERY clear statement of semantics to the contrary, I
  42. don't see how anyone can call code that makes this assumption obviously
  43. broken.
  44.  
  45. This is of course a rather trivial detail but is instructive with regard
  46. to the importance of writing precise specs. Kazimir's claim that the spec
  47. obviously requires that the buffer length match the requested, rather
  48. than actual length, based on some dubious reasoning about likely 
  49. implementation models is just the sort of thing that needs to be
  50. eliminated from programming practices. Specs need to be made precise,
  51. so that a caller knows EXACTLY what the requirements are without having
  52. to guess, or, worse still, examine the actual implementation code.
  53.  
  54.